redfish/drive: expose oem data and actions #366
Conversation
Signed-off-by: Matt Vandermeulen <[email protected]>
There was a problem hiding this comment.
I think this would be better addressed by adding the necessary OEM objects for this so you can access the OEM-specific properties and methods using the matching type for the hardware.
|
👍 I'll take a look at adding it over there. For SMC, should I follow the other pending change and use |
|
Hmm, good question. I don't have a strong opinion either way really. I think most folks who need it won't have any confusion equating smc to being for SuperMicro, so I'm fine with whatever you feel like doing. Thanks! |
|
I've added a commit that introduces the |
Signed-off-by: Matt Vandermeulen <[email protected]>
Signed-off-by: Matt Vandermeulen <[email protected]>
Signed-off-by: Matt Vandermeulen <[email protected]>
Signed-off-by: Matt Vandermeulen <[email protected]>
Signed-off-by: Matt Vandermeulen <[email protected]>
|
Nice work - thanks a lot! |
|
No problem! Do you have a sense for when the next release will be cut? Deciding whether to use my fork for now, or wait a bit and bump the version. |
|
You can use Otherwise, I'm probably going to add a few more Supermicro OEM things since I now have access to the hardware, then tag a release once I get at least some of the main objects in place. So I guess whatever is more convenient for you. |
We have some nodes that don't follow the typical indicator light flow that
Update()would handle. Instead, we have to hit a linked reference (with a variable key, sigh..) from the OEM section.I'm hoping to expose the
Oemfield in both theDriveand theDrive.Actions(while also exposing theActions) so that the user can follow that chain when necessary. This allows us to get the right link to where we need to send thePOSTorPATCH(also variable, heh) to enable lights for our datacenter folks.Tests updated to not lose secure erase functionality.